This section provides motivating examples that illustrate the changes in situations and requirements that affect the quality of software applications; in addition, it describes the problems that arise when the applications deal with changes based on an architectural selection method.

Software applications such as software systems in mobile devices are deployed in changing environments (e.g., the user moves). Also, they can encounter the user's requirement changes. The changing environments and requirements can be represented by situational changes and quality requirements changes, respectively. To describe the impacts of these changes on applications, this section provides three types of elements that constitute the dynamic architectural selection problem. The first element is quality attributes that the user concerns. The second element is situations that affect software architectures. The third element is possible functional alternatives. In addition, this section illustrates the interrelationships between situations, quality attributes, and alternatives.

On the basis of these elements, this section provides three examples. The first example shows changes in the interrelationships between situations, quality attributes, and alternatives when the current situation is changing. The second example illustrates changes in the interrelationships between them when the user's quality requirements (i.e., quality attributes that the user !j more requires) change. Then, we provide an example that shows the relationships between alternatives and architectural configurations.

\subsection{Situations, Quality Attributes, and Functional Alternatives}

Changing environments and user (quality) requirements affect software applications. In particular, applications are exposed to diverse factors such as the location where an application performs its function and the time when it performs its function. These factors lead to changes in application configurations to adapt to them. Suppose that a user launched applications in mobile devices such as smart phones. When the user moves from an indoor location to an outdoor location, the noise level of the environment can change (usually, it increases). This change may have an impact on the performance of an application (e.g., a sound alert reminding the user about an appointment may not be effective because of the background noise). To handle these changes, we need to know which aspect from environment and user requirements affects applications and which element in an application gets affected by that aspect.

First, situational changes in the environment exert a significant influence on the quality of an application. Changes in an environment can be represented by a set of several \emph{situation variables} that represent situational aspects in the environment. Suppose that a user executes application in mobile devices, the received signal strength indication (RSSI) level, battery level, and brightness are representative of situational aspects that can affect the quality of service of applications.
%The RSSI (Received Signal Strength Indication) level represents the quality of the device's wireless connection (usually denoted by ordinal values, such as $1, 2, \cdots , 5$). The battery level refers to the residual amount of batter current in the device. Brightness measures the intensity of the radiation of the location to which the device is exposed.
All these aspects have ordinal, nominal, or numerical values, e.g., RSSI and battery level can have ordinal values of $[low, middle, high]$ while the brightness level has integer values of $[0,255]$.


A change in the situation variables represents a change of environment. For example, if the current value of the situation variable ``RSSI level'' changes from ``low'' to ``high'', we can assume that the environment of an application has changed.
%The application that can be affected by this change must be aware of it.
To specify the contextual change of the environment, we can denote the environment as a vector of situation variables that may affect the quality of the application. For example, suppose that an application $A_1$ is related the RSSI level, battery level, and brightness. Then, a vector $<(rssi), (battery), (brightness)>$ can denote the contextual status of the environment (e.g., $<0, 1, 220>$ represents RSSI level = 0, Battery Level = 1, and Brightness = 220).
% The vector can express 6,144 situational changes (i.e., $6 \times 4 \times 256 = 6,144$; each number on the left side represents the number of possible values of RSSI level, battery level, and brightness variables, respectively).

%A change in situation variables represents a change of environment. For example, if the current value of the situation variable ``RSSI level'' changes from 1 to 5, we can assume that the environment of an application performed in the mobile device has changed. The application that can be affected by this change must be aware of it. To specify the contextual change of the environment, it can have a vector of situation variables that may affect the application's performance or behavior. For example, suppose that an application $A_1$ may concern RSSI level, battery level, and brightness. A vector $<(rssi), (battery), (brightness)>$ can denote the contextual status of the environment (e.g., $<0, 1, 220>$ represents RSSI level = 0, Battery Level = 1, and Brightness = 220). The vector can express 6,144 situational changes (i.e., $6 \times 4 \times 256 = 6,144$; each number on the left side represents the number of possible values of RSSI level, battery level, and brightness variables, respectively).


%\begin{figure}
%\centering \epsfig{fig/situations.eps, width=3.5in} \caption{Examples of situation variables that mobile applications can encounter.} \label{fig:situations}
%\end{figure}


There are two types of user requirements: functional and nonfunctional requirements. Functional requirements (FRs) include the system behaviors that must be observed in the software system. On the other hand, nonfunctional requirements (NFRs) address quality issues for software systems \cite{nfr}. NFRs deal with the degree of satisfaction. For example, using an authentication method in an application may satisfy security requirements \emph{at some level}. This concept is known as ``satisficing'' - \emph{sufficiently satisfactory}. This term was used by Herbert Simon in the 1950s \cite{simon1957}. In this paper, we deal only with changes in NFRs (quality requirements) because  applications are generally required to change their functions at runtime according to the user's changing requirements about the quality of service, rather than requirements about functional aspects. This study assumes that a user's quality requirements are represented by weight values that imply the priority of required quality attributes provided by the application.
% For example, a user may be more concerned about responsiveness of an application than security at runtime and he or she can request the application to change its configuration to be more responsive and less secure.
%Users of mobile applications usually do not request to change functional requirements (e.g., add a new function) because they may lead to long-term maintenance or revision in the development phase. Examples of quality attributes are shown in Figure \ref{fig:quality}.

%There are two types of user requirements: functional and non-functional requirements. Functional requirements (FRs) include the system behaviors that must be performed in the software system\cite{functional}. On the other hand, non-functional requirements (NFRs)\footnote{ In this paper, we will also use \textbf{quality attributes} to represent NFRs.} address quality issues for software systems\cite{nfr}. NFRs deal with the degree of satisfaction. For example, using an authentication method in an application may satisfy security requirements \emph{at some level}. This concept is known as ``satisficing'' - \emph{sufficiently satisfactory}. This term was used by Herbert Simon in the 1950s. In this paper, we deal only with changes of NFRs because mobile applications tend to be required to change their functions at runtime according to the user's changing requirements concerning the quality of service rather than functional aspects. For example, a user may be more concerned about responsiveness of an application than security at runtime and he or she can request the application to change its configuration to be more responsive and less secure. Users of mobile applications usually do not request to change functional requirements (e.g., add a new function) because they may lead to long-term maintenance or revision in the development phase. Examples of quality attributes are shown in Figure \ref{fig:quality}.

%\begin{figure}
%\centering \epsfig{fig/quality.eps, width=5.2in} \caption{Examples of quality attributes.} \label{fig:quality}
%\end{figure}

To adapt to changing situations and quality requirements, software applications can have diverse alternative functions, e.g., ``RichGUI,'' ``SimpleGUI,'' and ``NormalDisplay'' as shown in Figure \ref{fig:situ1}. These alternatives represent candidate functions that the application can select in case of changes in situations and quality requirements.
%As shown in Figure \ref{fig:alter},
Alternatives can be grouped by type. For example, ``HighContrastDisplay'' and ``NormalDisplay'' alternatives belong to the same type, ``Display''. In each type, only one alternative can be activated (e.g., ``NormalDisplay'' and ``HighContrastDisplay'' cannot coincide).

%To adapt to changing situations and quality attributes, a mobile application can have diverse alternative functions. These alternatives represent candidate functions that the application can take in situational and quality changes. As shown in Figure \ref{fig:alter}, alternatives can be grouped by a type. In each type, only one alternative or none can be activated (e.g., ``Normal Display'' and ``High Contrast Display'' in Figure \ref{fig:alter} cannot coincide).

%\begin{figure}
%\centering \epsfig{fig/alter.eps, width=5.2in} \caption{Examples of possible alternatives of mobile applications.} \label{fig:alter}
%\end{figure}

Each alternative has relationships with quality attributes, as shown in Figure \ref{fig:situ1}. For example, using a rich graphical user interface (GUI) may influence the application's usability and durability because while the rich GUI can provide a better user experience, it can also consume more battery life. This influence can be quantized to describe the relationship more specifically. For example, the high contrast display alternative can have a positive impact on readability (denoted by ``$+$'') but a more negative impact on durability (denoted by ``$--$''). These impacts can be aggregated for each quality attribute as shown in Figure \ref{fig:situ1} (denoted by real numbers on the top of each quality attributes -- responsiveness, usability, durability, and readability). Assume that the plus and minus signs denote ``$+1$'' and ``$-1$,'' respectively.
%Then, aggregate impact values on each quality attributes. For example, the score of usability is four because it is affected by both rich GUI and videotelephony alternatives, and they have impact values ``$+++$'' and ``$+$,'' respectively.
These aggregated scores can be used to measure how much the user is \emph{satisficed} with the quality attribute.

%Each alternative has relationships with quality attributes, as shown in Figure \ref{fig:qarealtion}. For example, using a rich GUI (Graphical User Interface) may influence the application's usability and durability because the rich GUI can provide a better user experience and consume more battery life. This influence can be quantized as shown in Figure \ref{fig:quantize}. The quantization of this relationship can describe the relationship more specifically. For example, the high contrast display alternative can have a positive impact on readability (denoted by ``$+$'') but a worse impact on durability (denoted by ``$--$''). These impacts can be aggregated for each quality attribute as shown in Figure \ref{fig:aggre}. Assume that the plus and minus signs denote ``$+1$'' and ``$-1$,'' respectively. Then, aggregate impact values on each quality attributes. For example, the score of usability is four because it is affected by both rich GUI and videotelephony alternatives, and they have impact values ``$+++$'' and ``$+$,'' respectively. These scores can be used to measure how much the user is \emph{satisficed}.

%\begin{figure}
%\centering \epsfig{fig/qarealtion.eps, width=5.2in} \caption{An example of relationships between functional alternatives and quality attributes.} \label{fig:qarealtion}
%\end{figure}
%
%
%\begin{figure}
%\centering \epsfig{fig/quantize.eps, width=5.2in} \caption{An example of relationship quantization.} \label{fig:quantize}
%\end{figure}
%
%
%\begin{figure}
%\centering \epsfig{fig/aggre.eps, width=5.2in} \caption{An example of aggregated scores for each quality attribute.} \label{fig:aggre}
%\end{figure}

To simply measure the degree of satisfaction for quality requirements, we can integrate the scores as shown in Figure \ref{fig:situ1}. Suppose that the user has weight values (i.e., quality requirements) that represent the priority of each quality attribute (0.2, 0.5, 0.1, and 0.2 for responsiveness, usability, durability, and readability, respectively). The weighted sum of the quality attributes is 0.8. This can be interpreted as the value of the selected alternatives: Rich GUI, High Contrast Display, and Videotelephony.

%To simply measure the degree of satisfaction for quality attributes, we can integrate the scores as shown in Figure \ref{fig:situ1}. Suppose that the user has the weight values (i.e., priority) of each quality attribute (0.2, 0.5, 0.1, and 0.2 for responsiveness, usability, durability, and readability, respectively). The weighted sum of the quality attributes is 0.8. This can be interpreted as the value of selected alternatives: Rich GUI, High Contrast Display, and Videotelephony.

The value of the selected alternatives can be a criterion to evaluate the selected alternatives to the current situation and the user's requirement represented by the weight values. Therefore, we can identify the best combination of alternative selection by evaluating the fitness values of all possible combinations. For example, we can calculate 18 combinations of the alternatives shown in Figure \ref{fig:situ1} (three of GUI, two of display, and three of messaging alternatives), and we can find the combination that has the maximum value. This combination will provide the best user experience.

%The value of the selected alternatives can be a criterion to evaluate the selected alternatives to the current situation and the user's requirement represented by weight values. Therefore, we can identify the best combination of alternative selection by evaluating values of all possible combinations. For example, we can calculate 18 combinations of the alternatives shown in Figure \ref{fig:situ1} (three of GUI, two of display, and three of messaging alternatives) and we can find one combination that has the maximum value. This combination will provide the best user experience.


\begin{figure}
\centering
%\scalebox{0.45}{\includegraphics{fig/situ1.eps}}
\includegraphics[width=0.5\textwidth]{fig/situ1.eps}
\caption{Example of value evaluation of selected alternatives (Rich GUI, High Contrast Display, and Videotelephony) in a given situation for which RSSI Level = 5, Battery Level = 3, and Brightness = 120.}
\label{fig:situ1}
\end{figure}


\subsection{Situational Changes}

The value of alternatives can be changed as the current situation changes. The value 0.8 in Figure \ref{fig:situ1} is valid in a situation where RSSI Level = 5, Battery Level = 3, and Brightness = 120. When the situation changes, the current value of the combination may not be valid and must be re-evaluated, as shown in Figure \ref{fig:situ2}. The value of the combination [Rich GUI, High Contrast Display, and Videotelephony] changes from $0.8$ to $-1.4$ because the impact of the alternatives on the quality attributes changes. For example, when the mobile device is exposed to a low RSSI level, the videotelephony function has a negative impact on responsiveness because it consumes more network resources than the other alternatives.

\begin{figure}
\centering
\includegraphics[width=0.5\textwidth]{fig/situ2.eps}
\caption{Example of value evaluation of selected alternatives (Rich GUI, High Contrast Display, and Videotelephony) in a given situation for which RSSI Level = 1, Battery Level = 1, and Brightness = 50.}
\label{fig:situ2}
\end{figure}


The application should change its configuration to adapt to the changed environment and to meet the user requirements when it identifies changes in the situation. When the situation changes, the application can re-evaluate the values of all combinations of alternatives and select the best one. In other words, for every situational change, the application can adapt to the current environment by reconfiguring its structure according to the optimal combination found at runtime; however, this will be time-consuming if a large number of alternatives are involved. This time-consuming task may lead to a delay and performance degradation in adaptation. Consequently, this can cause negative user experiences because the application cannot complete the adaptation process within the amount of time that the user can tolerate.

\begin{figure}
\centering
\includegraphics[width=0.5\textwidth]{fig/situ3.eps}
\caption{Example of value evaluation of selected alternatives (Rich GUI, High Contrast Display, and Videotelephony) in a given situation for which RSSI Level = 5, Battery Level = 3, and Brightness = 120; the weight values are 0.2, 0.2, 0.5, and 0.1 for responsiveness, usability, durability, and readability, respectively.}
\label{fig:situ3}
\end{figure}

\subsection{Quality Requirements Changes}

As in the case of situational changes, the application must change its configuration when the user changes quality requirements  (weight values on quality attributes). Although the application shown in Figure \ref{fig:situ3} has the same alternatives and monitors the same situation values as those in Figure \ref{fig:situ1}, the value of the selected alternatives can be changed by changing the weight value of each quality attribute.

The application must re-evaluate all combinations of alternatives to identify whether there are better alternatives that \emph{satisfice} the changed user requirements. This is also time-consuming. In addition, it is not possible to calculate all values prior to runtime because the number of combinations of weight values and situation values is not finite (in particular, weight values are usually real numbers in $[0,1]$). Therefore, the application should dynamically re-evaluate the values of combinations of alternatives to identify the best or near-optimal combinations in changing environments (i.e., at runtime).

\begin{figure}
\centering \includegraphics[width=0.5\textwidth]{fig/archexample1.eps}
\caption{Example of relationships between alternatives and an architectural configuration.}
\label{fig:archexample1}
\end{figure}



\subsection{Architectural Configurations}

After finding the best or near-optimal combination, the application must change its architectural configuration according to the selected combination. In other words, when the situation or user requirement changes, the application finds a combination of alternatives that are more appropriate for the current situation values and quality requirements (represented by weight values of quality attributes), and then changes its architectural configuration according to the combination. For example, as shown in Figure \ref{fig:archexample1}, the ``RichGUI'' and ``High Contrast Display'' alternative can correspond to the ``RichGUI'' and ``High Contrast Transformer'' component, respectively. The ``Videotelephony'' alternative can correspond to two components: ``Image Compressor'' and ``Audio Compressor.'' If the application observes changes from the environment or user, it subsequently changes its configuration according to the selected alternatives, as shown in Figure \ref{fig:archexample2}. In this manner, the application reconfigures its architecture when it encounters changes in situations and quality requirements.

Deriving an actual software architectural configuration from a combination of architectural decisions is also an important issue in software architecture research; however, this issue is not the focus of this paper. Moreover, previous studies have already dealt with this issue in terms of interface matching \cite{1370020} and prescribed reconfiguration strategies \cite{rainbow}. In this paper, we assume that (1) the software application that applies our approach is implemented by dynamic architectures that enable the application to reconfigure its configuration and (2) the developer of the application has to generate architectural alternatives (i.e., components) that constitute architectural configurations. This issue will be discussed in detail in Section \ref{sec:diss}.

\begin{figure}
\centering
\includegraphics[width=0.5\textwidth]{fig/archexample2.eps}
\caption{Example of relationships between alternatives and an architectural configuration.}
\label{fig:archexample2}
\end{figure}

The next section describes our approach to formulating this dynamic architectural selection problem using softgoal interdependency graphs, situation variables, and architectural decision variables. In addition, it describes how to efficiently select architectural instances in the formulation.


